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Amendments to the Drawings 

The attached Replacement Drawing Sheet containing Fig. 1 A replaces the originally-filed 
drawing sheet containing Fig. 1 A of this Application. The Replacement Drawing Sheet corrects 
the reference number for dialog box 44 illustrated in Fig. 1 A. 
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Remarks 

The Applicant has amended the first sentence of the specification to include the Related 
Applications section outlining the priority claim. The benefit claim was timely made and was 
recognized by the Office on the official filing receipt of the current application. As such, 
amendment without any petition is proper under M.P.E.P §201 .1 1 (III)(D). 

Claims 48-76 are currently pending in the present application. No new matter was added 
by this Amendment. Applicant respectfiiUy requests reexamination and reconsideration in view 
of the remarks contained herein. 

1. Claim Rejections under 35 USC § 103(a) 

Claims 48-76 stand rejected under 35 USC § 103(a) as being anticipated by U.S. Patent 
No. 6,026,398 issued to Brown et al. (hereinafter referred to as "Brown") in view of U.S. Patent 
No. 6,160,874 issued to Dickerman et al. (hereinafter referred to as "Dickerman"). As described 
below in more detail, Brown and Dickerman, taken individually or in combination, do not teach 
or suggest the subject matter of these claims. 

A. Independent Claim 48 

Independent Claim 48 recites: 

A debit data validation system for a network, the system comprising: 

a calling application configured to 

receive a request to validate debit data, and 

receive transactional debit data that is to be validated; 

a debit data search engine including a keying module and a matching 
module, wherein the debit data search engine is configured to 

receive the transactional debit data fi-om the calling application, 

and 

process the transactional debit data; and 

a debit data warehouse including stored debit data, wherein the stored 
debit data is representative of at least one consumer, and fiirther wherein at least 
one consumer key links the stored debit data representative of each of the at least 
one consumer. 
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Brown does not teach or suggest the subject matter of Claim 48. First, Brown does not 
teach or suggest "a calling application configured to receive a request to validate debit data, and 
receive transactional debit data that is to be validated," as recited in Claim 48. Rather, the 
subject matter of Brown concerns determining "database records which either closely or exactly 
match the input search data." Abstract. In particular, Brown discloses that the "input search data 
is broken down into elements, and elements are converted to terms having a finite set of possible 
values. ... The terms are compared against an index of terms to determine which database 
records relate to the input search data. Through statistical analysis, match records are given a 
record weight which may be used to calculate how closely the input data actually is to each 
match record." Abstract, Clearly, Brown merely discloses receiving input data, processing the 
input data, and determining matching database records based on the input data. Brown does not 
teach or suggest validating any type of data. Furthermore, Brown makes no mention whatsoever 
processing debit data or transactional debit data. Therefore, Brown clearly does not teach or 
suggest "a calling application configured to receive a request to validate debit data, and receive 
transactional debit data that is to be validated," as recited in Claim 48. 

Similarly, Brown does not teach or suggest "a debit data search engine including a 
keying module and a matching module, wherein the debit data search engine is configured to 
receive the transactional debit data from the calling application, and process the transactional 
debit data," as recited in Claim 48. First, as noted above. Brown makes no mention whatsoever 
of processing any type of debit data. Furthermore, Brown does not teach or suggest "a calling 
application" as recited in Claim 48. Therefore, Brown clearly does not teach or suggest "a debit 
data search engine... configured to receive the transactional debit data firom the calling 
application, and process the transactional debit data," as also recited in Claim 48. 

In addition. Brown does not teach or suggest "a debit data search engine including a 
keying module and a matching module," as recited in Claim 48. As described in the present 
application, in some embodiments, the "keying module 1222 of the debit data search engine 
1220 is utilized... to perform the keying process. ... The keying process Hnks debit data 
acquired fi-om a number of data sources... to form at least one consumer key or consumer 
identifier." Page 33, lines 17-24. In addition, the present application states that "the consumer 
keys. . .are stored in the debit data warehouse 1230." Page 34, lines 24-26. Brown does not teach 
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or suggest a search engine that includes a keying module. Rather, as noted above, Brown 
discloses obtaining input search data, breaking the search data into elements, converting the 
elements into terms having a finite set of possible values, and comparing the terms against an 
index in order to determine which database records relate to the input search data. Therefore, 
Brown merely discloses identifying and pulling matching database records from a single 
database. Brown does not teach or suggest receiving data from multiple sources or linking data 
received from multiple sources. Accordingly, Brown does not teach or suggest a keying module 
as recited in Claim 48. 

Brown also does not teach or suggest a matching module as recited in Claim 48. As 
described in the present application, in some embodiments, the "matching component includes 
matching debit data from the data sources 1300 (i.e., acquired debit data) against the debit data 
stored in the debit data warehouse 1230 (i.e., stored debit data). The matching component 
determines what acquired debit data can be linked to the stored debit data. ... If a match is 
found between the acquired debit data and the stored debit data, then the acquired data is 
additionally linked to the consumer key that is representative of the matched stored debit data." 
Page 35, lines 13-23. Brown does not disclose attempting to match and link data to data stored 
in a database. Rather, as noted above, Brown merely discloses identifying and pulling matching 
database records from a database. Brown makes no mention whatsoever of linking data to the 
data stored in the database. Therefore, Brown does not teach or suggest a matching module as 
recited in Claim 48. 

Furthermore, Brown does not teach or suggest "a debit data warehouse including stored 
debit data, wherein the stored debit data is representative of at least one consumer, and further 
wherein at least one consumer key links the stored debit data representative of each of the at least 
one consumer," as recited in Claim 48. As previously noted, Brown makes no mention 
whatsoever of storing or processing debit data. Therefore, Brown clearly does not teach or 
suggest "a debit data warehouse including stored debit data, wherein the stored debit data is 
representative of at least one consumer," as recited in Claim 48 (emphasis). 

In addition. Brown does not teach "at least one consumer key [that] links the stored debit 
data representative of each of the at least one consimier," as recited in Claim 48. As described in 
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the present application, in some embodiments, "[t]he debit data acquired from the data sources 
1300 is linked together to form at least one consumer key or consumer identifier. ... Each 
consxmier key may represent the overall debit worthiness picture of a particular consumer which 
is based only upon reliable debit data acquired from the data sources 1300." Page 33, lines 22- 
30. As described above, since Brown does not teach or suggest processing debit data, Brown 
clearly does not teach or suggest storing a consumer identifier, which is created based on linked 
debit data related to a consumer, hi fact. Brown makes no mention whatsoever of a link that 
associates data stored in a database with a particular consumer. 

Therefore, in summary. Brown does not teach or suggest "a calling application 
configured to receive a request to validate debit data, and receive transactional debit data that is 
to be validated;" "a debit data search engine including a keying module and a matching module, 
wherein the debit data search engine is configured to receive the transactional debit data from the 
calling application, and process the transactional debit data;" or "a debit data warehouse 
including stored debit data, wherein the stored debit data is representative of at least one 
consumer, and ftirther wherein at least one consumer key links the stored debit data 
representative of each of the at least one consumer," as recited in Clam 48. 

Dickerman does not cure the deficiencies of Brown. Rather, the subject matter of 
Dickerman concems a method for "receiving, converting protocol, and sending messages to 
process customer credit card requests." Col. 3, lines 63-65. In particular, Dickerman discloses 
systems and methods for establishing "[c]ommunication between teleconununications networks 
and computer systems used by financial institutions... [in order to process] customer requests to 
pay for telecommunication services with credit cards. ..." Abstract. 

As disclosed in Dickerman, "[t]he system... comprises a validation gateway that has a 
computer program that provides for the transfer of messages and conversion of protocol to allow 
communication between the telecommunications network that received the call and the computer 
system used by the financial institution that provides the customer with credit card services." 
Col. 3, lines 12-18. Dickerman also discloses that the "computer program on the validation 
gateway includes software modules that perform specific functions. Modules within the 
computer program of the validation gateway receive messages from and send messages to caller 
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interaction processors. Caller interaction processors are processors that allow a human operator 
to interact or interact directly with a debit customer to receive call processing information from 
customer." Col. 3, lines 24-31. 

As further disclosed in Dickerman, "[t]he method of the present invention includes the 
steps for receiving a validation request message from a caller interaction processor, building a 
card request message that can be understood by the financial processor, and sending the card 
request message to the financial processor. The method of present invention also includes the 
steps for receiving a card reply message from the financial processor, building a validation 
response message that can be understood by the caller interaction processor, and sending the 
validation response message to the caller interaction processor." Col. 3, lines 65-67 and Col. 4, 
lines 1-8. As disclosed in Dickerman, the validation request message "contains transaction data 
such as the customer's credit card account number, the credit card type, the expiration date of the 
credit card, and the amoimt the customer wishes to charge to the credit card." Col. 7, lines 43- 
47. 

Dickerman merely discloses a gateway that receives credit card authorization requests 
from a telecommunications network, converts the credit card authorization requests to a request 
understandable by a financial institution network, and forward the request to the financial 
institution network. The request does not include any debit data or transactional debit data. 
Therefore, Dickerman does not teach or suggest "a calling application configured to receive a 
request to validate debit data, and receive transactional debit data that is to be validated," as 
recited in Claim 48 (emphasis added). 

In addition, Dickerman does not teach or suggest "a debit data search engine including a 
keying module and a matching module, wherein the debit data search engine is configured to 
receive the transactional debit data from the calling application, and process the transactional 
debit data," as recited in Claim 48. First, as noted above, since Dickerman does not teach or 
suggest processing debit data, Dickerman clearly does not teach or suggest "a debit data search 
engine... configured to receive the transactional debit data from the calling application, and 
process the transactional debit data," as recited in Claim 48. 
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In addition, Dickerman does not teach or suggest "a debit data search engine including a 
keying module and a matching module," as recited in Claim 48. As noted above, in some 
embodiments, the keying module links debit data acquired from multiple sources in order to 
form customer links, and the matching module attempts to match debit data acquired from 
multiple sources to debit data stored in a debit data warehouse. The validation gateway disclosed 
in Dickerman performs none of these functions. First, the validation gateway only processes 
credit data. Second, the validation gateway disclosed in Dickerman does not attempt to match 
and link data acquired from multiple sources. Therefore, Dickerman clearly does not teach or 
suggest "a debit data search engine including a keying module and a matching module, wherein 
the debit data search engine is configured to receive the transactional debit data from the calling 
application, and process the transactional debit data," as recited in Claim 48. 

Furthermore, Dickerman does not teach or suggest "a debit data warehouse including 
stored debit data, wherein the stored debit data is representative of at least one consumer, and 
further wherein at least one consumer key links the stored debit data representative of each of the 
at least one consumer," as recited in Claim 48. As noted above, in some embodiments of the 
present invention, "[t]he debit data acquired from the data sources 1300 is linked together to 
form at least one consumer key or consumer identifier. . . . Each consumer key may represent 
the overall debit worthiness picture of a particular consumer which is based only upon reliable 
debit data acquired from the data sources 1300." Page 33, lines 22-30. Dickerman does not 
disclose a link that associates data stored in the database with a particular consumer. Although 
Dickerman discloses multiple databases used by the teleconmiunications network, the validation 
gateway, and the financial institution, Dickerman does not teach or suggest a link that associates 
debit data stored in a database with a particular consumer. 

Therefore, Brown and Dickerman, taken individually or in combination, do not teach or 
suggest "a calling application configured to receive a request to validate debit data, and receive 
transactional debit data that is to be validated;" "a debit data search engine including a keying 
module and a matching module, wherein the debit data search engine is configured to receive the 
transactional debit data from the calling application, and process the transactional debit data;" or 
"a debit data warehouse including stored debit data, wherein the stored debit data is 
representative of at least one consumer, and further wherein at least one consumer key links the 
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Stored debit data representative of each of the at least one consumer," as recited in Clam 48. 
Consequently, for at least the reasons set out above, independent Claim 48 and dependent Claims 
79-75, which depend on Claim 48, are allowable. Similar rationale can also be applied to 
independent Claim 76. Accordingly, Claims 48-76 are allowable for at least the reasons set out 
above. 
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II. Conclusion 

In light of the above, Applicant believes that the application is in condition for allowance 
and respectfully request that a timely Notice of Allowance be issued in this case. Applicant also 
requests that the Examiner telephone the attomeys of record in the event a telephone discussion 
would be helpful in advancing the prosecution of the present application. 
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